The development of software applications has historically yielded poor results related to customer's expectations for cost, time-to-market or quality of the delivered product. To improve perceived and actual success rates related to software development, it would be advantageous to employ software development method/approach analysis and construction strategies which address the fundamental complexity of selecting and deploying the optimal software development practice(s) and associated knowledge base at the correct time during a software development endeavor. Furthermore, it would be advantageous to automate the knowledge of how to make such a software development practice selection or set of selections using an expert system made widely available across the interne or similar computer network to dramatically lower the cost of software development project/endeavor improvement industry-wide.
A knowledge base contains encoded knowledge. In a rule-based expert system, the knowledge base typically incorporates definitions of facts and rules along with control information. An inference engine (sometimes referred to as a rule interpreter or rule engine) provides a reasoning mechanism in an expert system. In a rule based expert system, the inference engine typically implements forward chaining and backward chaining strategies. Forward chaining is a process of applying a set of previously determined rules to the facts in a knowledge base to see if any of them fire and thereby generate new facts. In essence, all derivable knowledge is derived in forward chaining. Backward chaining is goal-driven and used to process some queries against the knowledge base. A query is considered a goal and the knowledge base is searched for facts supporting that goal. Inference engines designed for expert systems are increasingly used in business automation.
A software development approach, also synonymous in industry with “method”, can be specified, described and documented using a set of practices as the components or “chunks”. A practice can be defined simply as the codified knowledge of a technique or set of techniques that together have proven effective in prior usage. Common industry approaches to software development include Lean, Agile, Lean-Agile, XP (eXtreme Programming), Scrum, DSDM (Dynamic Systems Development Method), RUP (Rational Unified Process), Unified Process, Agile-Unified Process, Kanban and the like.
A common aspect of each of these approaches to software development is that they can be decomposed into practices, each describing some experience on effective software development technique based on the context by which they emerged. Usage of these practices, whether considered individually or as part of a broader method or practice-set exhibit effectiveness in certain software development projects/endeavors and not in others. The context for such effectiveness serves as a basis for categorizing the appropriateness of the choices made to apply practices/sets of practices with typical categories being size, geographical distribution, domain/problem type and complexity, technical complexity, enterprise specialization, compliance/regulatory requirements, contractual constraints and requirements, criticality and loss-of funds or lives, time-to-market and corporate culture. While retroactive categorizing of the appropriateness of practices to context has been studied and documented in some instances, proactive determination of appropriateness and risk associated with combinations of practices has been historically complex, fragmented and limited in industry. Complicating this further is the historical norm to consider and categorize appropriateness of pre-defined sets of practices labeled as named or branded container methods for such evidence and not practices on their own.
The field of Situational Method Engineering has for some time struggled with the capabilities of how to select, assemble, compose, publish and present and enact methods based on the specific situation or set of contextual factors in which a software development endeavor exists. However, an underlying sound and credible basis for the aforementioned capabilities has eluded industry. Similarly, a sound and credible basis for correlating evidence of effectiveness to practice usage has suffered from a lack of an underlying model that enables the assessment, learning, refactoring, improvement, simulation and enactment of methods such that the performance and the risks that can be expected from such practice choices made on a software development project can be understood.
One common practice that has shown consistent performance correlation on software development projects is iteration or “iterative development”. While the software development industry generally agrees on the efficacy of this practice, what is not intuitive is the rationale. Specifically, what parameters applied to this practice make it effective and which do not, independent of the various synonyms given to essentially the same practice. What is non-obvious is that the central reason for such success can be modeled and explained as representing negative feedback within a closed-loop system configuration commonly leveraged in the field of Control Systems Engineering for influencing physical world dynamic system response problems.
Control Systems Engineering refers to a sub-field of General Systems Theory and is the engineering discipline that applies control theory to design systems with predictable behaviors. Control Theory is an interdisciplinary branch of engineering and mathematics that deals with the behavior of dynamical systems. Designs of system configurations within this field include but are not limited to Proportional-Integral-Derivative Control designs, Adaptive Control designs, Cascade Control designs, Optimal Control designs, Non-Linear Control designs and Stochastic Control designs.
Common study and design of the aforementioned system configurations is performed using Dynamic Systems modeling. Dynamic Systems models refer to time or frequency domain models of Single-Input-Single-Output (SISO) and Multiple-Input-Multiple-Output (MIMO) systems which includes but are not limited to Differential Equations, Laplace Transform or Fourier Transform representations, Transfer Function representation, Bode Analysis, Root Locus analysis, Nyquist Plots, Nichols Analysis, Pole placement analysis, and State-Space matrices.
Feedback within a closed-loop system provides customers and managers the ability to adjust course so as to achieve expected results and feedback has been studied and modeled extensively in the Control Systems Engineering field. It is to be recognized by the skilled artisan that all software development practices can be mapped onto such a model, with each practice concretely implementing one or more of a set of universally present generic practices that map to components that make up such system configurations. In other words, all software development practice knowledge can be reduced to a set of finite universal practices, which when specialized using concrete specific practices in various permutations and combinations covers all known software development methods. By combining practices together using control Systems Engineering designs, the resultant socio-technical system can be further modeled to explain practice choice implications. Such an observation also makes implementing an automated expert system feasible. It is non-obvious that practice advice and guidance can be achieved by leveraging Control Systems Engineering system designs and related bodies of knowledge. Such a design/set of designs provides a credible basis for providing advice on the composition, assessment, learning, improvement and simulation of software development approaches made up of practice building blocks.
In U.S. Pat. No. 20080097734 to David M. Raffo. for SYSTEM AND METHOD FOR SIMULATING GLOBAL PRODUCT DEVELOPMENT (hereinafter Raffo), a methodology, computer program and system is disclosed which relates to the simulation of global software development projects using a plurality of System Dynamics/Discrete Event models. The usage of models are further calibrated and improved by project result data as provided through the disclosed computer system program. In Raffo, what is claimed is specific usage of system dynamics/discrete event models in the embodiment described therein. However, such modeling approaches differ from Dynamic Systems modeling as commonly utilized within the field of Control Systems Engineering, generally seen as the ancestor to the modeling approaches used in Raffo. System Dynamics and Discrete Event models, while typically used for the simulation of systems and their dynamic responses, including socio-technical systems as described in Raffo through reference to Global Software Development projects, are time-domain models only and are more complex, containing a large number of model elements that suffer from intractability to common software development practitioners for the purposes of visualization and learning. Moreover, models used in the method and system of Raffo do not lend themselves to construction of a system of practices leveraging what is known from the Control Systems Engineering field.